{
    title:  'Security',
    crumbs: [
        { "User's Guide": 'index.html' },
    ],
}
            <h1>Security Considerations</h1>
            <p>Securing applications that are accessible to the Internet is not a trivial task. This page outlines some
            of the issues, and offers best-practices and tips to help you secure your application using Embedthis Appweb.</p>
            
            <h2>Contents</h2>
            <ul>
                <li><a href="#updates">Updating Appweb</a></li>
                <li><a href="#sandBoxing">Sandboxing</a></li>
                <li><a href="#account">Appweb User Account</a></li>
                <li><a href="#directoryPermissions">File Permissions</a></li>
                <li><a href="#chroot">Chroot Jail</a></li>
                <li><a href="#ssl">Securing SSL</a></li>
                <li><a href="#authentication">Authentication</a></li>
                <li><a href="#logFiles">Log Files</a></li>
                <li><a href="#high">High Profile Threats</a></li>
                <li><a href="#threats">Common Security Threats</a></li>
                <li><a href="#frameworks">Frameworks</a></li>
            </ul>
            
            <a id="updates"></a>
            <h2>Updates</h2>
            <p>Even the best application or HTTP server can experience some security vulnerabilities that are
            discovered after being deployed in the field. It is highly recommended that you stay up to date with the
            latest version of Appweb.</p>
            <p><a href="http://www.embedthis.com/">Embedthis</a> provides security protection 
            as part of the Appweb commercial license that will proactively notify you of any security flaws
            and will expedite fixes or workarounds to minimize any vulnerabilities.</p>
            
            <a id="sandBoxing"></a>
            <h2>Sandboxing</h2>
            <p>Sandboxing is the term applied to running Appweb in a confined environment. When embedding a HTTP server,
            the profile of client access is often well known, and the profile of malicious attacks are well outside this
            profile. The profile includes the rate of accesses, the length of URLs and the size of pages returned to the
            user.</p>
            <p>Appweb has a set of configuration file directives that allow you to define a sandbox which specifies how
            Appweb must be used for a request to be serviced. By using well defined sandbox directives, you can help
            ensure that your application will not be compromised by malicious requests. You should customize the
            sandbox limits to use minimum values and thus provide the most protection.</p>
            <h3>Security Limit Directives</h3>
            <p>The Appweb security limits can be used to effectively block some denial of service attacks. 
            Limits should be set as low as possible while still permitting all valid requests and workloads.</p>
            <p>Setting the LimitRequestsPerClient to a low value can restrict the ability of a malicious client to monopolize
            the server. One attack method for denial of service attacks is to initiate requests, but not conclude the
            request headers. The server is then forced to wait for the client to complete the request before it can
            act. However, setting the RequestParseTimeout directive to a low value will abort such requests and prevent
            such attacks.</p>
            <p>Appweb can monitor sandbox limits and trigger defensive responses if access is outside defined norms. See the
            <a href="#dos">Denial of Service</a> section for more details.</p>
            <p>The important security limit directives are:</p>
            <table title="sandbox" class="ui table segment">
                <tbody>
                    <tr>
                        <td class="pivot">InactivityTimeout</td>
                        <td>Maximum request and connection inactivity duration. This can be defined per route, so if you
                            have a long running request, create a dedicated route for that request.</td>
                    </tr>
                    <tr>
                        <td class="pivot">LimitClients</td>
                        <td>Maximum number of simultaneous clients</td>
                    </tr>
                    <tr>
                        <td class="pivot">LimitConnections</td>
                        <td>Maximum number of network connections. Note a client can open many network connections. A browser
                            session will typically open 4-6 connections.</td>
                    </tr>
                    <tr>
                        <td class="pivot">LimitRequestsPerClient</td>
                        <td>Maximum number of simultaneous requests from a single client IP</td>
                    </tr>
                    <tr>
                        <td class="pivot">RequestParseTimeout</td>
                        <td>Maximum duration to parse the request headers. This should be set very short. 
                            Typically a browser will send all the request headers in one network packet. Recommended
                            value is 5 secs.</td>
                    </tr>
                    <tr>
                        <td class="pivot">RequestTimeout</td>
                        <td>Maximum request duration. Set this to the maximum time a request can take. This can
                            be defined per route, so if you have a long running request, create a dedicated
                            route and RequestTimeout for it.</td>
                    </tr>
                </tbody>
            </table>
            <h3>Sandbox Limit Directives</h3>
            <p>The additional sandbox limit directives are:</p>
            <table title="sandbox" class="ui table segment">
                <tbody>
                    <tr>
                        <td class="pivot">LimitBuffer</td>
                        <td>Pipeline stage buffer size</td>
                    </tr>
                    <tr>
                        <td class="pivot">LimitCache</td>
                        <td>Maximum size of the response cache</td>
                    </tr>
                    <tr>
                        <td class="pivot">LimitCacheItem</td>
                        <td>Maximum size of a single item in the response cache</td>
                    </tr>
                    <tr>
                        <td class="pivot">LimitChunk</td>
                        <td>Maximum size of chunks when using Transfer Chunk Encoding</td>
                    </tr>
                    <tr>
                        <td class="pivot">LimitKeepAlive</td>
                        <td>Maximum number of requests to serve using a single TCP/IP connection</td>
                    </tr>
                    <tr>
                        <td class="pivot">LimitMemory</td>
                        <td>Maximum memory the server can allocate</td>
                    </tr>
                    <tr>
                        <td class="pivot">LimitProcesses</td>
                        <td>Maximum number of simultaneous CGI processes the server will start</td>
                    </tr>
                    <tr>
                        <td class="pivot">LimitRequestBody</td>
                        <td>Maximum size of the incoming request body. Does not include file upload size.</td>
                    </tr>
                    <tr>
                        <td class="pivot">LimitRequestForm</td>
                        <td>Maximum size of request form data (POST data)</td>
                    </tr>
                    <tr>
                        <td class="pivot">LimitRequestHeader</td>
                        <td>Maximum size of the request header</td>
                    </tr>
                    <tr>
                        <td class="pivot">LimitRequestHeaderLines</td>
                        <td>Maximum number of header lines in the request</td>
                    </tr>
                    <tr>
                        <td class="pivot">LimitResponseBody</td>
                        <td>Maximum size of a response</td>
                    </tr>
                    <tr>
                        <td class="pivot">LimitUri</td>
                        <td>Maximum size of a URI</td>
                    </tr>
                    <tr>
                        <td class="pivot">StartThreads</td>
                        <td>Number of threads to pre-allocate in the thread pool</td>
                    </tr>
                    <tr>
                        <td class="pivot">LimitUpload</td>
                        <td>Maximum size of a file upload request</td>
                    </tr>
                    <tr>
                        <td class="pivot">LimitWorkers</td>
                        <td>Maximum number of worker threads to service requests. A single worker may service many requests
                            as Appweb will typically not block when serving a request. Workers are assigned to service network 
                            events and are then returned to a worker pool to service the next event.</td>
                    </tr>
                </tbody>
            </table>
            <p>See the <a href="dir/sandbox.html">Sandbox Directives</a> for further details.</p>
            <a id="account"></a>
            <h2>Appweb User Account</h2>
            <p>It is important that you run Appweb with the lowest system privilege that will get the job done. If any
            application is compromised, including Appweb, then the system will be safest if the compromised application
            has as few privileges as possible.</p>
            <h3>Unix Account</h3>
            <p>On Unix, Appweb initially runs as root or administrator and then changes to the user account defined in
            the Appweb configuration file via the <a href="dir/server.html#user">User</a> directive. As installed,
            Appweb will be configured to run in the <b>nobody</b> account on Unix. You may modify the user and group
            account for Appweb by changing the Appweb <a href="configuration.html">configuration file</a>.</p>
            <h3>Windows Account</h3>
            <p>On Windows, when running as a system service, Appweb will run using the LocalSystem account. This account
            has no privileges to access the network using network drives, named pipes, RPC or DCOM. However, it has
            considerable privileges locally. It is suggested that you create a dedicated account for Appweb to minimize
            the privileges available should Appweb be compromised.</p>
            <p>When creating an account for Appweb, ensure you do the following:</p>
            <ul>
                <li>Using the Group Policy manager, grant the account the privilege of "Act as part of the operating
                system" and "Log on as a service".</li>
                <li>Ensure the account is a member of the "Users" group.</li>
                <li>Give the account read and execute rights to all HTML documents.</li>
                <li>Give the account read, write, execute and delete rights to the logs directory.</li>
                <li>Give the account read and execute rights to the appweb.exe and the DLLs in the libs directory.</li>
            </ul>
            <a id="directoryPermissions"></a>
            <h2>Directory and File Permissions</h2>
            <p>When Appweb is installed, it is configured for maximum security. This section explains the policy 
            should you need to move or modify files and directories.</p>
            <p>To enhance security you need to consider the directory and file permissions for three classes of
            content:</p>
            <ul>
                <li>Pages served by the HTTP server</li>
                <li>Scripts run by the HTTP server</li>
                <li>Configuration and log files used by the HTTP server.</li>
            </ul>
            <p>Pages served by the Appweb server should be owned by root or administrator and should be only readable
            by the Appweb user account. Directories containing served pages should be readable and executable only.</p>
            <p>Scripts run by the Appweb server should always be outside all directories containing served pages. After
            all, you don't want prying eyes viewing your scripts! Scripts should be owned by the <b>root</b> or
            <b>administrator</b> and should only be readable and executable by the Appweb user account.</p>
            <p>Configuration and log files used by the Appweb server should always be outside all directories
            containing served pages or scripts. The directory containing the log files must be writable by the Appweb
            user account.</p>
            <h3>Home Directory Permissions</h3>
            <p>The root directory for Appweb is called the Home directory and is defined by the Home
            directive in the configuration file. The Home directory, and the logs and lib directory below it,
            should be owned by <b>root</b> (or admin), and should be in the group <b>root</b> (or administrators). They
            should only be writable by this specific user and group.</p>
            <p>For Linux, these commands will ensure the privileges are correctly set up:</p>
            <pre class="ui code segment">
cd    /etc/appweb
chown root . lib logs
chgrp root . lib logs
chmod 755  . lib logs
</pre>
            <a id="chroot"></a>
            <h2>Chroot Jail</h2>
            <p>One of the best forms of isolation for the server is to run inside a 
            <a href="http://en.wikipedia.org/wiki/Chroot">chroot</a> jail. A chroot jail is when an application changes
            its root directory to be isolated from the real file system root directory. Any access then to files outside the jail is protected and impossible. Appweb supports chroot jails via the 
            <a href="dir/server.html#chroot">chroot</a> directive and via the appweb --chroot command line option.</p>
            <p>See also the <a href="https://github.com/embedthis/appweb/tree/dev/samples/chroot-server"
                >Chroot Sample</a> for a working example.</p>
            <a id="ssl"></a>
            <h2>Securing SSL</h2>
            <p>If you configure a SSL virtual server, remember to define a separate Documents directory if you want to only serve private content to SSL users. Otherwise those pages will also be visible via the default server.</p>
            <h3>Cipher Selection</h3>
            <p>It is important to select a sufficiently long key length and strong cipher to protect SSL communications. It is recommended to use the AES cipher and avoid the older RC4 cipher suite. See the section below regarding 
            <a href="#threats">Common Security Threats</a> for threats against the RC4 ciphers. </p>
            <h3>SSL Forms</h3>
            <p>A common practice is to use HTTP for regular communications and to post login forms using SSL. However, this approach is flawed. The web form itself must be served using SSL as well as the URL receiving the login information. This prevents attackers injecting code into the form and hijacking login credentials.</p>
            <p>For more information regarding SSL, please read: </p>
            <ul>
                <li><a href="sslOverview.html">SSL Overview</a></li>
                <li><a href="ssl.html">Configuring SSL</a></li>
            </ul>
            <a id="authentication"></a>
            <h2>Authentication</h2>
            <p>It is important to adequately secure all passwords stored at the server. Simply hashing the passwords with MD5 is now insufficient as MD5 and other "fast" hashing techniques can be quickly compromised by dedicated password cracking and hashing tools.</p>
            <p>Appweb includes the blowfish cipher as an alternative that is more secure than MD5. The <a href="http://en.wikipedia.org/wiki/Blowfish_(cipher)">Blowfish</a> cipher is especially well suited for password hashing partly. Partly because it is slow, it does not easily succumb to brute-force cracking. </p>
            <p>If you wish to use the Digest authentication scheme, unfortunately you cannot use blowfish as the browser uses MD5 to encrypt the password before transmitting over the wire. This and other shortcomings of Digest authentication should encourage you to select other schemes. A better alternative is Basic authentication over SSL using blowfish to encrypt the passwords. Alternatively, use web form authentication with blowfish for password storage.</p> 
            <p>If using a web page for users to submit their credentials, it is strongly recommended that you use SSL for both the web form page and for the request validating the user credentials.</p>
            <a id="logFiles"></a>
            <h2>Log Files</h2>
            <p>Appweb will log satisfied requests to the access log (usually logs/access.log) and errors to the error
            log (usually logs/error.log). It is recommended that you regularly review these logs for suspicious
            activity.</p>
            <a id="threats"></a>
            <h2>Common Security Threats</h2>
            <p>This section details some common security threats and issues and the steps you can take to mitigate them.</p>
            <h3>Server Information Disclosure</h3>
            <p>HTTP responses often disclose information that an attacker can use to refine their attack. At a minimum, too much information enables the attack to proceed faster. Appweb includes a stealth directive that suppresses unnecessary information. Here is a typical HTTP response from Appweb</p>
            <pre class="ui code segment">
HTTP/1.1 200 OK
Content-Type: text/html
<b>Server: Embedthis-http</b>
Date: Thu, 15 Aug 2014 22:10:25 GMT
ETag: "cf4ce71-54-51c64a0b"
Content-Length: 84
Last-Modified: Sun, 23 Jun 2014 01:06:19 GMT
Connection: close
Accept-Ranges: bytes</pre>
            <p>Note that by default, Appweb does not disclose the web server version number in HTTP headers. </p>
            <pre class="ui code segment">Stealth on</pre>
            <pre class="ui code segment">
HTTP/1.1 200 OK
Content-Type: text/html
Date: Thu, 15 Aug 2014 22:11:46 GMT
ETag: "cf4ce71-54-51c64a0b"
Content-Length: 84
Last-Modified: Sun, 23 Jun 2014 01:06:19 GMT
Connection: close
Accept-Ranges: bytes
</pre>
            <p>See that the <i>Stealth</i> directive has suppressed the Server header altogether. Attackers will need to work
            a little harder to know what kind of web server is responding to their requests &mdash; they may move onto
            another target.</p>
            <h3>Session Hijacking</h3>
            <p>Cookies are used to identify authenticated user sessions. As such, they are a prized piece of information 
            by attackers. The HTTP Set-Cookie response header has an option to prevent client side scripts from ascertaining
            the session cookie value. This can greatly reduce the risk of session hijacking via cross-site scripting.</p>
            <pre class="ui code segment">SessionCookie invisible</pre>
            <p>This directive Appweb to append the "httpOnly" value to the Set-Cookie response so the cookie will only be 
            accessible to HTTP requests.</p>
            <pre class="ui code segment">Set-Cookie: key=value; httpOnly</pre>
            <a name="mixed"></a>
            <h3>Mixed Transports</h3>
            <p>Is is a bad idea to mix secure and non-secure content in one page. This means a web page should be totally served by HTTP or by HTTPS but not mix transports on one page. The reason is that a page served by HTTP can be compromised and the guarantee of HTTPS and that green-browser https logo is diminished if the form page from
            which the user enters there data is not 100% trust-worthy.</p>
            <p>Appweb provides a directive to enable a "Strict-Transport-Security" HTTP response header. This instructs the browser that all connections thereafter must only request over HTTPS. The specified age limit is in seconds.
            To enable this, use the following directive:</p>
            <pre class="ui code segment">Require secure age=31536000</pre>
            <a name="dos"></a>
            <h3>Denial of Service</h3>
            <p>Denial of service attacks can be difficult to detect and defend against. However, Embedded devices typically have a well defined, understood and anticipated work load. Unlike enterprise system, which have highly variable work loads, embedded systems typically serve a specific purpose with known clients that follow a more predictable access pattern. This allows an embedded system to define a range of operation that is considered "normal" and to trigger alerts and defenses if access is outside of this "normal" operation.</p>
            <p>Appweb provides a <a href="monitor.html">Monitor and Defending</a> framework that can detect many denial of service attacks. The defensive policies can alert and mitigate the attack and help maintain service. It is recommended that all systems consider this framework.</p>
            <h3>Cross Site Scripting</h3>
            <p>Cross-site vulnerabilities have ballooned over recent years. Unfortunately, there is no, single complete cure.
            However, Appweb supports the <a href="http://en.wikipedia.org/wiki/Content_Security_Policy"
                >Content Security Policy (CSP)</a> scheme that can go a long way to reduce the exposure. It does this by
            exactly specifying and restricting what cross-site access is permitted.</p>
            <p>The following Appweb directive enables the Content Security Policy and restricts all access to the origin
            site. This is a good starting point.</p>
            <pre class="ui code segment">Header set Content-Security-Policy default-src 'self'</pre>
            <p>See <a href="http://www.html5rocks.com/en/tutorials/security/content-security-policy/"
                >An introduction to Content Security Policy</a> for more information.</p>
            <p>For Microsoft IE, there is another step specific for IE that is useful. The following Appweb directive
            invokes some additional IE cross site protections.</p>
            <pre class="ui code segment">Header set X-XSS-Protection 1; mode=block</pre>
            <h3>Cross Site Sharing</h3>
            <p>Cross origin sharing is often required when using XMLHttp (Ajax) requests to communicate with another server.
            <a href="http://en.wikipedia.org/wiki/Cross-origin_resource_sharing">Cross Origin Resource Sharing (CORS)</a> is
            a mechanism that allows scripts to make XMLHttp requests to another domain different from that which served the 
            web page. This relaxes the same-origin policy of the browser, but in a controlled manner.</p>
            <p>The Appweb <a href="dir/route.html#crossOrigin">CrossOrigin</a> directive defines:</p>
            <pre class="ui code segment">CrossOrigin origin=http://www.google.com credentials=yes age=3000</pre>
            <h3>Hidden Frames</h3>
            <p>Hidden frames may be inserted by attackers to provide a launch-pad for running malicious scripts. Denying 
            the ability to run frames can close of this attack vector.</p>
            <p>The following Appweb directive will prevent frames or iframes from running in the web page.</p>
            <pre class="ui code segment">Header set X-Frame-Options deny</pre>
            <a name="high"></a>
            <h2>High Profile Threats</h2>
            <p>There have been several high profile exploits that pose specific risks and have captured media attention.
            These are addressed specifically below with details on how to mitigate their effects.</p>
            <h3>Crime Exploit</h3>
            <p>The <a href="http://en.wikipedia.org/wiki/CRIME_(security_exploit)">Crime Security Exploit</a> attacks and
            exploits leakage of information due to the varying effectiveness of TLS compression.
            <ul>
               <li>Access to intercept and redirect client communications</li>
               <li>Ability to initiate requests from the client</li>
               <li>Encrypted communications SSL/TLS</li>
               <li>TLS level compression</li>
            </ul>
            <p>By default, Appweb does not use TLS with TLS compression and is thus not vulnerable to this exploit. 
            The OpenSSL SSL_COMP_add_compression_method will enable TLS compression, so it is important not to use this
            OpenSSL API.</p>
            <h3>Breach Exploit</h3>
            <p>The <a href="http://breachattack.com">Breach</a> exploit is a variant of the Crime exploit. It attacks and
            discovers private server information, such as CSRF tokens, by observing the compression of HTTP responses over
            SSL. This exploit requires the following to be effective:</p>
            <ul>
                <li>Access to intercept and redirect client communications</li>
                <li>Ability to initiate requests from the client</li>
                <li>Encrypted communications SSL/TLS</li>
                <li>Server-side encryption of dynamic responses</li>
                <li>Unmodified inclusion in the response body of client specified query or form data</li>
            </ul>
            <p>Appweb does not dynamically compress response content and so is not vulnerable to this exploit.</p>
            <h3>Beast Exploit</h3>
            <p>The <a href="http://en.wikipedia.org/wiki/BEAST_(computer_security)#BEAST_attack">Beast Security Exploit</a>
            attacks block ciphers used by TLS to access encrypted packets.
            This exploit requires the following to be effective:</p>
            <ul>
                <li>Use of TLS 1.0. This exploit has been addressed in TLS 1.1 and later.</li>
                <li>Ability to position attacker as man-in-the-middle between server and client</li>
                <li>Encrypted communications SSL/TLS</li>
                <li>Using a block cipher.</li>
            </ul>
            <p>Notes:</p>
                <ul>
                    <li>OpenSSL 0.9.6d and later are not vulnerable.</li>
                    <li>Appweb 3.3 and later have shipped with fixed OpenSSL libraries.</li>
                    <li>Using RC4 will mitigate the attack if upgrading OpenSSL is not feasible, however this cipher
                    is vulnerable to the Luck 13 exploit described below.</li>
                </ul>
            <h3>Lucky 13 Exploit</h3>
            <p>The <a href="http://www.isg.rhul.ac.uk/tls/TLStiming.pdf">Lucky 13</a> exploit attacks TLS by using varying
            padding for block ciphers. </p>
            <p>This exploit requires the following to be effective:</p>
            <ul>
                <li>Ability to position attacker as man-in-the-middle between server and client</li>
                <li>Encrypted communications SSL/TLS</li>
                <li>Using a block cipher.</li>
                <li>Use of the RC4 cipher.</li>
            </ul>
            <p>Notes:</p>
            <ul>
                <li>Mitigate by not using an RC4 cipher</li>
                <li>RC4 was not the default cipher in any Appweb release</li>
            </ul>
            <a name="cve"></a>
            <h2>Documented Vulnerabilities</h2>
            <p>Appweb documents discovered security errors in its GitHub issue database 
            at </p>
            <pre class="ui code segment"><a href="https://github.com/embedthis/appweb/issues?state=open"
            >https://github.com/embedthis/appweb/issues?state=open</a></pre>
            <p>Specific issue reports are created for all confirmed or erroneous 
            security reports that receive a CVE classification. You can search for specific 
            CVE numbers or see all via:</p>
            <pre class="ui code segment"><a
href="https://github.com/embedthis/appweb/search?q=CVE-&amp;type=Issues">https://github.com/embedthis/appweb/search?q=CVE-&amp;type=Issues</a></pre>
            <p>Unfortunately some security researchers publish poorly diagnosed security alerts and sometimes do not contact the vendor for confirmation of the report. Consequently there exist some security CVE reports which are bogus. Appweb creates parallel CVE issues in the Appweb GitHub issue database to comment on these reports and provide accurate resolution information.</p>
            <h2>Other Security References</h2>
            <p>Some of these articles may provide good background regarding security web servers.</p>
            <ul>
                <li><a href="http://www.isg.rhul.ac.uk/tls/TLStiming.pdf"
                    >http://www.isg.rhul.ac.uk/tls/TLStiming.pdf</a></li>
                <li><a href="http://blog.cryptographyengineering.com/search?q=bram+cohen"
                    >http://blog.cryptographyengineering.com/search?q=bram+cohen</a></li>
                <li><a href="http://html5sec.org/">http://html5sec.org/</a></li>
                <li><a href="https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet"
                    >https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet</a></li>
                <li><a href="https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)"
                    >https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)</a></li>
                <li><a href="https://www.owasp.org/images/b/be/Cracking-into-embedded-devices-and-beyond.pdf"
                    >https://www.owasp.org/images/b/be/Cracking-into-embedded-devices-and-beyond.pdf</a></li>
                <li><a href="http://media.blackhat.com/bh-ad-11/Sutton/bh-ad-11-Sutton_Embeded_Web_Servers_WP.pdf"
                    >http://media.blackhat.com/bh-ad-11/Sutton/bh-ad-11-Sutton_Embeded_Web_Servers_WP.pdf</a></li>
                <li><a href="http://www.imperialviolet.org/2012/07/19/hope9talk.html"
                    >http://www.imperialviolet.org/2012/07/19/hope9talk.html</a></li>
                <li><a href="https://www.owasp.org/images/b/be/Cracking-into-embedded-devices-and-beyond.pdf"
                    >https://www.owasp.org/images/b/be/Cracking-into-embedded-devices-and-beyond.pdf</a></li>
            </ul>
            <a id="frameworks"></a>
            <h2>Frameworks</h2>
            <p>Appweb supports several Web Frameworks for creating dynamic content. These frameworks sometimes require
            special security considerations because they are executing code or scripts to render the content.</p>

            <h2>Embedded Server Pages</h2>
            <p>ESP applications are not immune to security flaws. It is highly recommended that
            you use the <a href="../ref/api/mpr.html">MPR</a> services for all your ESP code. This portable runtime
            has been extensively tested and includes routines to guard against common buffer overflows and other such
            exploits.</p>
            <a name="securedefaults"></a>
            <h2>Appweb Secure By Default</h2>
            <p>Appweb is designed to be secure by default. This means that the default configuration enables 
            security best-practices to limit cross-site-scripting vulnerabilities. It also implies a fairly
            restrictive security sandbox. This default configuration may be a little too restrictive for your application. 
            In that case, you can easily remove or override these defaults by the relevant Appweb directives.</p>
            <p>Appweb uses the following built-in configuration for the default route.</p>
            <pre class="ui code segment">
Header set X-XSS-Protection         "1; mode=block"
Header set X-Frame-Options          "deny"
Header set X-Content-Type-Options   "nosniff"
SessionCookie           invisible
Stealth                 on
InactivityTimeout       30secs
RequestParseTimeout     5sec
RequestTimeout          5mins
SessionTimeout          5mins
LimitConnections        50
LimitProcesses          10
LimitRequestsPerClient  20
LimitRequestBody        128K
LimitRequestForm        128K
LimitUpload             unlimited
LimitUri                512
LimitWebSockets         25
LimitWebSocketsPacket   8K
LimitWebSocketsFrame    4K
LimitWorkers            5
</pre>
            <p>The default Content Security Policy header is set to only permit content loaded from the server running
            appweb. It also bans inline scripts as these are vulnerable to inline script injection.
            See <a href="http://www.html5rocks.com/en/tutorials/security/content-security-policy/">An Introduction to
                Content Security Policy</a> for more information.</p>
            <p>You can override these directives globally in the main section of appweb.conf or locally in a specific route.
            (Except for LimitProcesses which always applies globally). You can remove the default security headers via:
<pre class="ui code segment">
Header remove X-XSS-Protection
Header remove X-Frame-Options
Header remove X-Content-Type-Options
</pre>
            <p>Other directives worth considering are:</p>
            <pre class="ui code segment">
Chroot "."
Defense deny REMEDY=ban STATUS=406 MESSAGE="Client banned" PERIOD=10mins
Monitor "NotFoundErrors &gt; 190" 5sec deny
Monitor "RequestsPerClient &gt; 200" 5sec deny
</pre>
